home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc1344.txt < prev    next >
Text File  |  1994-08-01  |  26KB  |  587 lines

  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.             Network Working Group               N. Borenstein, Bellcore
  8.             Request for Comments: 1344                        June 1992
  9.  
  10.                   Implications of MIME for Internet Mail Gateways
  11.  
  12.  
  13.           Status of This Memo
  14.  
  15.             This is an informational memo for  the  Internet  community,
  16.             and  requests  discussion  and suggestions for improvements.
  17.             This  memo  does   not   specify   an   Internet   standard.
  18.             Distribution of this memo is unlimited.
  19.  
  20.           Abstract
  21.  
  22.             The recent development of MIME (Multipurpose  Internet  Mail
  23.             Extensions)  offers  a  wide  range of new opportunities for
  24.             electronic mail system systems.  Most of these  opportunites
  25.             are relevant only to user agents, the programs that interact
  26.             with human users when they send and receive mail.   However,
  27.             some  opportunities  are  also  opened up for mail transport
  28.             systems.  While MIME was carefully designed so that it  does
  29.             not  require  any  changes  to  Internet  electronic message
  30.             transport  facilities,  there  are  several  ways  in  which
  31.             message  transport  systems  may  want  to take advantage of
  32.             MIME.  These opportunities are the subject of this memo.
  33.  
  34.           Background -- The MIME Format
  35.  
  36.             Recently, a new standardized format  has  been  defined  for
  37.             enhanced  electronic  mail  messages  on the Internet.  This
  38.             format, known as MIME, permits messages  to  include,  in  a
  39.             standardized  manner,  non-ASCII  text, images, audio, and a
  40.             variety of other kinds of interesting data.
  41.  
  42.             The  MIME  effort  was  explicitly  focused   on   requiring
  43.             absolutely  no  changes  at  the  message  transport  level.
  44.             Because of this fact, MIME-format mail runs transparently on
  45.             all  known  Internet  or  Internet-style mail systems.  This
  46.             means that those concerned solely with the  maintenance  and
  47.             development  of message transport services can safely ignore
  48.             MIME completely, if they so choose.
  49.  
  50.             However, the fact that MIME can be ignored, for the  purpose
  51.             of  message  transport,  does  not  necessarily mean that it
  52.             should be  ignored.   In  particular,  MIME  offers  several
  53.             features that should be of interest to those responsible for
  54.             message transport services. By  exploiting  these  features,
  55.             transport  systems  can  provide certain additional kinds of
  56.             service that are currently unavailable, and can alleviate  a
  57.             few existing problems.
  58.  
  59.             The remainder of this document  is  an  attempt  to  briefly
  60.             point  out  and  summarize some important ways in which MIME
  61.  
  62.  
  63.  
  64.             Borenstein                                          [Page 1]
  65.  
  66.  
  67.  
  68.  
  69.             RFC 1344           MIME and Mail Gateways          June 1992
  70.  
  71.  
  72.             may be of use for message transport systems.  This  document
  73.             makes no attempt to present a complete technical description
  74.             of MIME, however.  For that, the reader is  refered  to  the
  75.             MIME document itself [RFC-1341].
  76.  
  77.           Mail Transport and Gateway Services:  A Key Distinction
  78.  
  79.             Before implementing any of the mechanisms discussed in  this
  80.             memo,  one  should  be familiar with the distinction between
  81.             mail transport service and mail gateway service.  Basically,
  82.             mail  transport software is responsible for moving a message
  83.             within a homogeneous electronic mail service network.   Mail
  84.             gateways,  on  the  other  hand,  exchange  mail between two
  85.             significantly different  mail  environments,  including  via
  86.             non-electronic services, such as postal mail.
  87.  
  88.             In general, it is widely considered  unacceptable  for  mail
  89.             transport  services  to  alter the contents of messages.  In
  90.             the case of mail gateways, however, such alteration is often
  91.             inevitable.  Thus, strictly speaking, many of the mechanisms
  92.             described here apply only to gateways,  and  should  not  be
  93.             used  in  simple  mail  transport  systems.   However, it is
  94.             possible that some very special situations -- e.g., an  SMTP
  95.             relay   that  transports  mail  across  extremely  expensive
  96.             intercontinental network  links  --  might  need  to  modify
  97.             messages,  in order to provide appropriate service for those
  98.             situations, and hence must redefine its role to be that of a
  99.             gateway.
  100.  
  101.             In this memo, it is assumed that transformations which alter
  102.             a message's contents will be performed only by gateways, but
  103.             it is recognized that some existing  mail  transport  agents
  104.             may  choose to reclassify themselves as gateways in order to
  105.             perform the functions described here.
  106.  
  107.           Rejected Messages
  108.  
  109.             An unfortunately frequent duty of message transport services
  110.             is  the  rejection  of  mail to the sender.  This may happen
  111.             because the mail was undeliverable, or because  it  did  not
  112.             conform  to  the requirements of a gateway (e.g., it was too
  113.             large).
  114.  
  115.             There has never been a standard format for rejected messages
  116.             in  the  past.   This has been an annoyance, but not a major
  117.             problem for text messages.  For non-text messages,  however,
  118.             the  lack  of  a  standard rejection format is more crucial,
  119.             because rejected messages typically appear to be  text,  and
  120.             the  user  who  finds  himself viewing images or audio as if
  121.             they were text is rarely happy with the result.
  122.  
  123.             MIME makes it very easy to encapsulate messages  in  such  a
  124.             way  that  their  semantics  are  completely preserved.  The
  125.             simplest way to do this is to make each rejection  notice  a
  126.  
  127.  
  128.  
  129.             Borenstein                                          [Page 2]
  130.  
  131.  
  132.  
  133.  
  134.             RFC 1344           MIME and Mail Gateways          June 1992
  135.  
  136.  
  137.             MIME  "multipart/mixed"  message.   That  multipart  message
  138.             would contain two parts, a text part explaining  the  reason
  139.             for  the  rejection,  and  an encapsulated message part that
  140.             contained the rejected message itself.
  141.  
  142.             It should be stressed that the transport software  does  not
  143.             need  to understand the structure of the rejected message at
  144.             all.  It  merely  needs  to  encapsulate  it  properly.  The
  145.             following,  for  example,  shows how any MIME message may be
  146.             encapsulated in a rejection message in such a way  that  all
  147.             information  will be immediately visible in the correct form
  148.             if the  recipient  reads  it  with  a  MIME-conformant  mail
  149.             reader:
  150.  
  151.                  From: Mailer-Daemon <daemon@somewhere.com>
  152.                  Subject: Rejected Message
  153.                  Content-type: multipart/mixed; boundary=unique-boundary
  154.  
  155.                  --unique-boundary
  156.                  Content-type: text/plain; charset=us-ascii
  157.  
  158.                  A mail message you sent was rejected.  The details of
  159.                  the rejected message are as follows:
  160.  
  161.                  From: Nathainel Borenstein <nsb@bellcore.com>
  162.                  Message-ID: <12345@bellcore.com>
  163.                  To: bush@whitehouse.gov
  164.                  Subject: I know my rights!
  165.                  Rejection-reason:  No mail from libertarians is
  166.                  accepted.
  167.  
  168.                  The original message follows below.
  169.                  --unique-boundary
  170.                  Content-type: message/rfc822
  171.  
  172.                  The ENTIRE REJECTED MESSAGE, starting with the headers,
  173.                  goes here.
  174.  
  175.                  --unique-boundary--
  176.             In  the  above  example,  the  ONLY  thing   that   is   not
  177.             'boilerplate"  is the choice of boundary string.  The phrase
  178.             "unique-boundary" should be replaced by a string  that  does
  179.             not  appear  (prefixed  by  two  hyphens) in any of the body
  180.             parts.
  181.  
  182.             Encapsulating a message in this manner is very easily  done,
  183.             and  will  constitute  a  significant  service  that message
  184.             transport services can perform for MIME users.
  185.  
  186.             IMPORTANT NOTE:  The format given above  is  simply  one  of
  187.             many possible ways to format a rejection message using MIME.
  188.             Independent IETF efforts are needed in order to  standardize
  189.             the format of rejections and acknowledgements.
  190.  
  191.  
  192.  
  193.  
  194.             Borenstein                                          [Page 3]
  195.  
  196.  
  197.  
  198.  
  199.             RFC 1344           MIME and Mail Gateways          June 1992
  200.  
  201.  
  202.           Fragmenting and Reassembling Large Messages
  203.  
  204.             One  problem  that  occurs  with  increasing  frequency   in
  205.             Internet  mail  is the rejection of messages because of size
  206.             limitations.   This  problem  can  be   expected   to   grow
  207.             substantially  more  severe  with the acceptance of MIME, as
  208.             MIME invites the use of very large objects  such  as  images
  209.             and audio clips.  Fortunately, MIME also provides mechanisms
  210.             that can help alleviate the problem.
  211.  
  212.             One particularly relevant MIME  type  is  "message/partial",
  213.             which  can  be  used  for  the  automatic  fragmentation and
  214.             reassembly of large mail messages.  The message/partial type
  215.             can be handled entirely at the user agent level, but message
  216.             transport services can also make use of this type to provide
  217.             more intelligent behavior at gateways.
  218.  
  219.             In particular, when gatewaying mail to or from a  system  or
  220.             network  known  to enforce size limitations that are more or
  221.             less stringent than are enforced locally, message  transport
  222.             services  might  choose either to break a large message into
  223.             fragments, or (perhaps less likely) to reassemble  fragments
  224.             into  a  larger  message.   The  combination  of  these  two
  225.             behaviors can make the  overall  Internet  mail  environment
  226.             appear more complete and seamless than it actually is.
  227.  
  228.             Details on the message/partial format may be  found  in  the
  229.             MIME  document.   What follows is an example of how a simple
  230.             short message  might  be  broken  into  two  message/partial
  231.             messages.   In  practice,  of  course,  the  message/partial
  232.             facility would only be likely to be  used  for  much  longer
  233.             messages.
  234.  
  235.             The following initial message:
  236.  
  237.                  From:  Nathaniel Borenstein <nsb@bellcore.com>
  238.                  To: Ned Freed: <ned@innosoft.com>
  239.                  Subject: a test message
  240.                  Content-type: image/gif
  241.                  Content-Transfer-Encoding: base64
  242.  
  243.                  R0lGODdhQAGMAbMAAAAAAP/u7swzIu6ZiLsiEd1EM+5VRGaI3WYAAO67qkRV
  244.                  uwARd6q7/ywAAAAAQAGMAUME/hDISau9OOvNu/9gKI6kRJwoUa5s675wLM90l
  245.                  XW5YKxqPyKRygxv2dr4czwlMCZrQLFTYHBJ2hlyQYFiaz+i0WWBou7fOq1x8vXWfU
  246.                  qU1fJ2qEhYaHGjhZQmJ2QT1xBW1ak1xUdV0/VjtsbpUEDaEJCQOIpqeoNV+LXo5W
  247.                  fVN3dZKceAQPvgyhwQ2lqcXGxx5wja59eJIGUNCszF90sYp50CoqFZ4DoqMMo6M
  248.  
  249.             can  be  transformed,  invertibly,  into  the  following two
  250.             message/partial messages:
  251.  
  252.  
  253.                  From:  Nathaniel Borenstein <nsb@bellcore.com>
  254.  
  255.  
  256.  
  257.  
  258.  
  259.             Borenstein                                          [Page 4]
  260.  
  261.  
  262.  
  263.  
  264.             RFC 1344           MIME and Mail Gateways          June 1992
  265.  
  266.  
  267.                  To: Ned Freed <ned@innosoft.com>
  268.                  Subject: a test message
  269.                  Content-type: message/partial; id="xyx@host.com";
  270.                       number=1; total=2
  271.  
  272.                  Content-type: image/gif
  273.                  Content-Transfer-Encoding: base64
  274.  
  275.                  R0lGODdhQAGMAbMAAAAAAP/u7swzIu6ZiLsiEd1EM+5VRGaI3WYAAO67qkRV
  276.  
  277.             and
  278.  
  279.                  From:  Nathaniel Borenstein <nsb@bellcore.com>
  280.                  To: Ned Freed <ned@innosoft.com>
  281.                  Subject: a test message
  282.                  Content-type: message/partial; id="xyx@host.com";
  283.                       number=2; total=2
  284.  
  285.                  uwARd6q7/ywAAAAAQAGMAUME/hDISau9OOvNu/9gKI6kRJwoUa5s675wLM90l
  286.                  XW5YKxqPyKRygxv2dr4czwlMCZrQLFTYHBJ2hlyQYFiaz+i0WWBou7fOq1x8vXWfU
  287.                  qU1fJ2qEhYaHGjhZQmJ2QT1xBW1ak1xUdV0/VjtsbpUEDaEJCQOIpqeoNV+LXo5W
  288.                  fVN3dZKceAQPvgyhwQ2lqcXGxx5wja59eJIGUNCszF90sYp50CoqFZ4DoqMMo6M
  289.  
  290.             Fragmenting such messages rather than rejecting  them  might
  291.             be  a  reasonable option for some gateway services, at least
  292.             for a certain range of message  sizes.   Of  course,  it  is
  293.             often  difficult for a gateway to know what size limitations
  294.             will  be encountered "downstream",  but intelligent  guesses
  295.             are often possible.  Moreover, an IETF working group on SMTP
  296.             extensions has proposed augmenting SMTP with a  "SIZE"  verb
  297.             that   would   facilitate  this  process,  thereby  possibly
  298.             requiring  fragmentation   on   the   fly   during   message
  299.             transmission.
  300.  
  301.             Note also that fragmentation or reassembly might  reasonably
  302.             be  performed,  in  differing  circumstances,  by either the
  303.             sending or receiving gateway  systems,  depending  on  which
  304.             system knew more about the capabilities of the other.
  305.  
  306.           Using or Removing External-Body Pointers
  307.  
  308.             Another MIME type oriented to extremely  large  messages  is
  309.             the  "message/external-body" type.  In this type of message,
  310.             all or part of the body data is not included in  the  actual
  311.             message  itself.   Instead,  the  Content-Type  header field
  312.             includes information that tells how the  body  data  can  be
  313.             retrieved -- either via a file system, via anonymous ftp, or
  314.             via other mechanisms.
  315.  
  316.             The message/external-body type provides  a  new  option  for
  317.             mail  transport  services  that  wishes  to optimize the way
  318.             bandwidth resources are used in a  given  environment.   For
  319.             example, the basic use of message/external-body is to reduce
  320.             bandwidth in email traffic. However, when  email  crosses  a
  321.  
  322.  
  323.  
  324.             Borenstein                                          [Page 5]
  325.  
  326.  
  327.  
  328.  
  329.             RFC 1344           MIME and Mail Gateways          June 1992
  330.  
  331.  
  332.             slow and expensive boundary -- e.g., a satellite link across
  333.             the Pacific -- it might make  sense  to  retrieve  the  data
  334.             itself  and  transform  the external-body reference into the
  335.             actual data.  Alternately, it might make sense to  copy  the
  336.             data  itself  to  a  new  location,  closer  to  the message
  337.             recipients, and  change  the  location  pointed  to  in  the
  338.             message.    Because   the  external-body  specification  can
  339.             include an expiration date, message transport  services  can
  340.             trade  off  storage  and  bandwidth  capabilities  to try to
  341.             optimize  the  overall  use  of  resources  for  very  large
  342.             messages.
  343.  
  344.             Such behaviors by a  gateway  require  careful  analysis  of
  345.             cost/benefit   tradeoffs  and  would be a dramatic departure
  346.             from  typical  mail  transport   services.    However,   the
  347.             potential  benefits  are quite significant, so that such the
  348.             appropriate use of these service options should be explored.
  349.  
  350.             For example, the following message includes PostScript  data
  351.             by external reference:
  352.  
  353.                  From:  Nathaniel Borenstein <nsb@bellcore.com>
  354.                  To: Ned Freed <ned@innosoft.com>
  355.                  Subject: The latest MIME draft
  356.                  Content-Type: message/external-body;
  357.                       name="BodyFormats.ps";
  358.                       site="thumper.bellcore.com";
  359.                       access-type=ANON-FTP;
  360.                       directory="pub";
  361.                       mode="image";
  362.                       expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
  363.  
  364.                  Content-type: application/postscript
  365.  
  366.             A gateway to Australia might choose to copy the file  to  an
  367.             Australian  FTP archive, changing the relevant parameters on
  368.             the Content-type header field.  Alternately, it might choose
  369.             simply  to  transform  the message into one in which all the
  370.             data were included:
  371.  
  372.                  From:  Nathaniel Borenstein <nsb@bellcore.com>
  373.                  To: Ned Freed <ned@innosoft.com>
  374.                  Subject: The latest MIME draft
  375.                  Content-type: application/postscript
  376.  
  377.                  %!PS-Adobe-1.0
  378.                  %%Creator: greenbush:nsb (Nathaniel Borenstein,MRE 2A-
  379.                  274,4270,9938586,21462)
  380.                  etc...
  381.  
  382.             This is an example which suggests both the benefits and  the
  383.             dangers.  There  is considerable benefit to having a copy of
  384.             the data immediately  available,   but  there  also  may  be
  385.             considerable  expense involved in transporting it to all  of
  386.  
  387.  
  388.  
  389.             Borenstein                                          [Page 6]
  390.  
  391.  
  392.  
  393.  
  394.             RFC 1344           MIME and Mail Gateways          June 1992
  395.  
  396.  
  397.             a the members of a list, if only a few  will  use  the  data
  398.             anytime soon.
  399.  
  400.             Alternatively, instead of replacing an external-body message
  401.             with  its real contents, it might make sense to transform it
  402.             into a "multipart/alternative" message containing  both  the
  403.             external  body  reference  and  the  expanded version.  This
  404.             means that only the external body part can be  forwarded  if
  405.             desired,  and  the recipient doesn't lose the information as
  406.             to where the data was fetched from, if they want to fetch an
  407.             up-to-date version in the future.  Such information could be
  408.             represented, in MIME, in the following form:
  409.  
  410.                  From:  Nathaniel Borenstein <nsb@bellcore.com>
  411.                  To: Ned Freed <ned@innosoft.com>
  412.                  Subject: The latest MIME draft
  413.                  Content-type: multipart/alternative; boundary=foo
  414.  
  415.                  --foo
  416.                  Content-Type: message/external-body;
  417.                       name="BodyFormats.ps";
  418.                       site="thumper.bellcore.com";
  419.                       access-type=ANON-FTP;
  420.                       directory="pub";
  421.                       mode="image";
  422.                       expiration="Fri, 14 Jun 1991 19:13:14 -0400 (EDT)"
  423.  
  424.                  Content-type: application/postscript
  425.                  --foo
  426.                  Content-type: application/postscript
  427.  
  428.                  %!PS-Adobe-1.0
  429.                  %%Creator: greenbush:nsb (Nathaniel Borenstein,MRE 2A-
  430.                  274,4270,9938586,21462)
  431.                  etc...
  432.                  --foo--
  433.  
  434.             Similarly for the case where a message is copied to a  local
  435.             FTP  site,  one  could  offer two external body parts as the
  436.             alternatives, allowing the user agent to  choose  which  FTP
  437.             site is preferred.
  438.  
  439.           Image and other Format Conversions
  440.  
  441.             MIME currently defines  two  image  formats,  image/gif  and
  442.             image/jpeg.   The  former  is  much more convenient for many
  443.             users, and can be displayed more quickly  on  many  systems.
  444.             The  latter  is  a  much  more  compact  representation, and
  445.             therfore places less stress on mail transport facilities.
  446.  
  447.             Message  transport  services  can  optimize  both  transport
  448.             bandwidth  and  user  convenience by intelligent translation
  449.             between these formats (and other formats that might be added
  450.             later).   When  a message of type image/gif is submitted for
  451.  
  452.  
  453.  
  454.             Borenstein                                          [Page 7]
  455.  
  456.  
  457.  
  458.  
  459.             RFC 1344           MIME and Mail Gateways          June 1992
  460.  
  461.  
  462.             long-haul delivery, it might  reasonably  be  translated  to
  463.             image/jpeg.   Conversely,  when  image/jpeg data is received
  464.             for  final  delivery  on  a  system  with  adequate  storage
  465.             resources,  it  might  be  translated  to  image/gif for the
  466.             convenience of the recipient.   Software  to  perform  these
  467.             translations  is  widely  available.   It  should  be noted,
  468.             however,  that  performance  of  such  conversions  presumes
  469.             support for the new format by the recipient.
  470.  
  471.             Although MIME currently only defines one audio format,  more
  472.             are  likely  to  be  defined and registered with IANA in the
  473.             future.  In that case, similar format conversion  facilities
  474.             might be appropriate for audio.
  475.  
  476.             If format conversion is done,  it  is  STRONGLY  RECOMMENDED
  477.             that some kind of trace information (probably in the form of
  478.             a Received header field) should be added  to  a  message  to
  479.             document the conversion that has been performed.
  480.  
  481.             Some people have expressed concerns,  or  even  the  opinion
  482.             that  conversions  should  never be done.  To accomodate the
  483.             desires of those who dislike the idea  of  automatic  format
  484.             conversion.   For  this  reason,  it  is suggested that such
  485.             transformations be generally restricted to  gateways  rather
  486.             than  general  message transport services, and that services
  487.             which perform such conversions  should  be  sensitive  to  a
  488.             header field that indicates that the sender does not wish to
  489.             have any such conversions performed.  A suggested value  for
  490.             this header field is:
  491.  
  492.             Content-Conversion: prohibited
  493.  
  494.             User agents that wish to explicitly indicate  a  willingness
  495.             for such conversions to be performed may use:
  496.  
  497.             Content-Conversion: permitted
  498.  
  499.             However,  this  will  be  the  default  assumption  of  many
  500.             gateways,  so  this  header field is not strictly necessary.
  501.             It also should be noted  that  such  control  of  conversion
  502.             would only be available to the sender, rather than to any of
  503.             the recipients.
  504.  
  505.  
  506.  
  507.  
  508.  
  509.  
  510.  
  511.  
  512.  
  513.  
  514.  
  515.  
  516.  
  517.  
  518.  
  519.             Borenstein                                          [Page 8]
  520.  
  521.  
  522.  
  523.  
  524.             RFC 1344           MIME and Mail Gateways          June 1992
  525.  
  526.  
  527.           Robust Encoding of Data
  528.  
  529.             In addition to all the  reasons  given  above  for  possible
  530.             transformation  of  body data, it will sometimes be the case
  531.             that a gateway can tell that the body data, as  given,  will
  532.             not  robustly  survive  the  next  step  of  transport.  For
  533.             example, mail crossing an ASCII-to-EBCDIC gateway will  lose
  534.             information  if certain characters are used.  In such cases,
  535.             a gateway can make the data more robust simply  by  applying
  536.             one of the MIME Content-Transfer-Encoding algorithms (base64
  537.             or quoted-printable) to the body or body  part.   This  will
  538.             generally  be  a  loss-less transformation, but care must be
  539.             taken  to  ensure  that  the  resulting  message  is   MIME-
  540.             conformant  if  the inital message was not.  (For example, a
  541.             MIME-Version header field may need to be added.)
  542.  
  543.           User-oriented concerns
  544.  
  545.             If a gateway is going to perform major transformations on  a
  546.             mail  message,  such as translating image formats or mapping
  547.             between included data and external-reference data, it  seems
  548.             inevitable that there will be situations in which users will
  549.             object to these transformations.  This is, in large part, an
  550.             implementation  issue,  but  it  seems  advisable,  wherever
  551.             possible, to provide a mechanism whereby users can  specify,
  552.             to  the  transport  system,  whether  or  not they want such
  553.             services performed automatically on their behalf. The use of
  554.             the  "Content-Conversion"  header field, as mentioned above,
  555.             is suggested for this purpose, since it  it  least  provides
  556.             some control by the sender, if not the recipient.
  557.  
  558.           References
  559.  
  560.             [RFC-1341]    Borenstein,   N.,   and   N.   Freed,    "MIME
  561.             (Multipurpose  Internet  Mail  Extensions):  Mechanisms  for
  562.             Specifying and Describing the  Format  of  Internet  Message
  563.             Bodies", RFC 1341, Bellcore, June, 1992.
  564.  
  565.           Security Considerations
  566.  
  567.             Security issues are not  discussed in this memo.
  568.  
  569.           Author's Address
  570.  
  571.             Nathaniel S. Borenstein
  572.             MRE 2D-296, Bellcore
  573.             445 South St.
  574.             Morristown, NJ 07962-1910
  575.  
  576.             Email: nsb@bellcore.com
  577.             Phone: +1 201 829 4270
  578.             Fax:  +1 201 829 7019
  579.  
  580.  
  581.  
  582.  
  583.  
  584.             Borenstein                                          [Page 9]
  585.  
  586.  
  587.